Hello all - well, the title of this article is probably not quite right, but did not know how to name this.
Our predicament - we have a layout dxl, which is about 1600 lines long, not sure whether this matters, unfortunately I can not post this.
The strange thing about it is, that, [ I set the view containing this layout dxl as the default view - ] We close the open module and then re-open it for the second time - NO errors are reported and the view (layout dxl column) works ! When the module has a different view as default and we open the module, no errors are displayed until we open the view for display, it then reports the same 60 odd errors at the first load of the view, we have to reload the view to make it work. We suspected that the {Carriage Return LineFeed} <CRLF> had something to do with it and only entered a <CR> at the end of each line of the code, but it made no difference. Any help, hints, tips, assistance be very much appreciated. thanks in advance Werner wernerK - Mon Nov 25 17:11:28 EST 2013 |
Re: Layout dxl not working Hi Werner, The run time nature of DXL layout scripts can raise a number of performance issues and side effects if the volume of code that has to be interpreted each time the layout script is executed is very long. If the include file is not local to the client or is perhaps on a network share for multi user access, then that will contribute to performance issues as the include file will be slower to read compared to having all of the code in line. Perhaps experiment by copying all of the include file code to the DXL layout script, remove the Include declaration and see if the same problem arises. Converting the DXL layout to DXL attribute is worth a try as a means to isolate the problem, this is also possibly a better way to go in the long run unless it's essential that the DXL script has to be running in real time. The observed problem where the errors seem to only appear after the initial loading of the View and then do not appear again on subsequent loading of the View suggests that maybe some upper time out limit has been reached with the DXL interpreter upon initial loading and executiion of such a long script and external include file. This possibly settles down after the inital loading perhaps due to performance gains from data caching.
Paul Miller
|
Re: Layout dxl not working PRM - Mon Nov 25 18:06:54 EST 2013 Hi Werner, The run time nature of DXL layout scripts can raise a number of performance issues and side effects if the volume of code that has to be interpreted each time the layout script is executed is very long. If the include file is not local to the client or is perhaps on a network share for multi user access, then that will contribute to performance issues as the include file will be slower to read compared to having all of the code in line. Perhaps experiment by copying all of the include file code to the DXL layout script, remove the Include declaration and see if the same problem arises. Converting the DXL layout to DXL attribute is worth a try as a means to isolate the problem, this is also possibly a better way to go in the long run unless it's essential that the DXL script has to be running in real time. The observed problem where the errors seem to only appear after the initial loading of the View and then do not appear again on subsequent loading of the View suggests that maybe some upper time out limit has been reached with the DXL interpreter upon initial loading and executiion of such a long script and external include file. This possibly settles down after the inital loading perhaps due to performance gains from data caching.
Paul Miller
Thank you Paul, appreciated. I tried to place the code inside a DXL attribute, but with the same behaviour observed. In regard to the time out limit, it seems unlikely to stem from that because the errors reported indicate a "simple" syntax error rather than a time out limit. I did not specify this, I am sorry. When I placed it into a DXL attribute, the I get a "simple" 'Attribute DXL failed' error message. When placed in a DXL layout column it reports - on initial load of view -
Where Line 21 in the code is this:
Where Line 73 in the code is this: and so fourth, basically reporting an error for most variables declared thanks Werner
|
Re: Layout dxl not working PRM - Mon Nov 25 18:06:54 EST 2013 Hi Werner, The run time nature of DXL layout scripts can raise a number of performance issues and side effects if the volume of code that has to be interpreted each time the layout script is executed is very long. If the include file is not local to the client or is perhaps on a network share for multi user access, then that will contribute to performance issues as the include file will be slower to read compared to having all of the code in line. Perhaps experiment by copying all of the include file code to the DXL layout script, remove the Include declaration and see if the same problem arises. Converting the DXL layout to DXL attribute is worth a try as a means to isolate the problem, this is also possibly a better way to go in the long run unless it's essential that the DXL script has to be running in real time. The observed problem where the errors seem to only appear after the initial loading of the View and then do not appear again on subsequent loading of the View suggests that maybe some upper time out limit has been reached with the DXL interpreter upon initial loading and executiion of such a long script and external include file. This possibly settles down after the inital loading perhaps due to performance gains from data caching.
Paul Miller
Hi, Same behavior for me not only in Layout DXL but also when running DXL scripts from customized menu options. I run my DXL locally or from a shared network folder. I always receive a syntax error the first time, and no error the other ones. Never found a reason. I just explain my users that it happens... Regards, Alain
|
Re: Layout dxl not working A 1600 line Layout is surely a disaster, as it can run multiple times per second for each displayed objects. Definately turn that into an Attr-DXL. "syntax" errors in a line are almost always fixed by adjusting some previous line; so we'd want to see ings 19, 20, 71, and 72 as well. In any event we would want to see the 1st and 2nd DXL errors, not those further down. I note that since you are getting DXL errors at very early lines, it seems that you could indeed post the 1st 22 lines of your code. As for causes; let me brain storm: [1] I wonder if you have some post-module-open trigger for all modules in the database that issues some kind of "evalTop_" command. This command resolves the include file references for FUTURE layouts. [2] My hackles are up vis-a-vis some PTSD I've experienced working with layouts. I wonder, does this view feature OTHER layouts or attr-DXL in columns adjacent to this one? If so, copy the view then remove those columns and see if you still have a problem. If you do not maybe I can <explain> as best I can what just happened. [3] Do you have some kind of <pragma encoding> command in your offending code? -Louie |
Re: Layout dxl not working llandale - Tue Nov 26 09:43:48 EST 2013 A 1600 line Layout is surely a disaster, as it can run multiple times per second for each displayed objects. Definately turn that into an Attr-DXL. "syntax" errors in a line are almost always fixed by adjusting some previous line; so we'd want to see ings 19, 20, 71, and 72 as well. In any event we would want to see the 1st and 2nd DXL errors, not those further down. I note that since you are getting DXL errors at very early lines, it seems that you could indeed post the 1st 22 lines of your code. As for causes; let me brain storm: [1] I wonder if you have some post-module-open trigger for all modules in the database that issues some kind of "evalTop_" command. This command resolves the include file references for FUTURE layouts. [2] My hackles are up vis-a-vis some PTSD I've experienced working with layouts. I wonder, does this view feature OTHER layouts or attr-DXL in columns adjacent to this one? If so, copy the view then remove those columns and see if you still have a problem. If you do not maybe I can <explain> as best I can what just happened. [3] Do you have some kind of <pragma encoding> command in your offending code? -Louie @adevicq - we never had this happen before - therefore we are trying to get to the bottom of this.
I did convert it to Attr-DXL and it shows the same behaviour - so no diff there, but sure will consider this option. there are no triggers in any of the modules - none no other dxl layouts are involved only a single pragma declared as - pragma runLim, 0 I can unfortunately not share the code here - sorry - but all the parts which report errors are actually comments, which is the strangest thing. comments of what the code will do ... nothing more - comments are preceeded by the normal two // The seventh line of the code is actually a #include to call a file which holds all attribute declarations, we might have to turn this around somehow. cheers Werner |
Re: Layout dxl not working wernerK - Tue Nov 26 17:28:12 EST 2013 @adevicq - we never had this happen before - therefore we are trying to get to the bottom of this.
I did convert it to Attr-DXL and it shows the same behaviour - so no diff there, but sure will consider this option. there are no triggers in any of the modules - none no other dxl layouts are involved only a single pragma declared as - pragma runLim, 0 I can unfortunately not share the code here - sorry - but all the parts which report errors are actually comments, which is the strangest thing. comments of what the code will do ... nothing more - comments are preceeded by the normal two // The seventh line of the code is actually a #include to call a file which holds all attribute declarations, we might have to turn this around somehow. cheers Werner no matter what we are changing and modifying the error persists - I did raise a PMR now to get to the bottom of this. Thank you all for your help
|
Re: Layout dxl not working wernerK - Mon Dec 02 16:49:53 EST 2013 no matter what we are changing and modifying the error persists - I did raise a PMR now to get to the bottom of this. Thank you all for your help
Hey Werner, does the DXL actually fail with an error (i.e. after loading the view, do you see an error message in the view column) or does the DXL Layout just pop up the DXL Interaction window with the errors and then show a result? If the DXL is not failing, chances are, that the DXL layout is opening a module which will either have a failing DXL Layout, DXL Attribute or trigger attached to it. If this is the case, see if after the first opening of the module other modules are opened invisibly. Close the modules, then open the problematic view a 2nd time. If the error appears again you should be able to find the problematic module, by tracing the load / read / edit /share calls. Just an idea. Another possibility where we have the effect of an error message appearing only once is autodeclare! If your script is turning on autodeclare, then chances are, that the first time you open the view, the layout DXL will fail (since autodeclare is turned off, even if it is the first statement in the file, because the DXL file was loaded before AutoDeclare was activated. We had a discussion about autodeclare here! ). Then for the second time (after the statement has been run), the next time the DXL Layout is loaded autodeclare will be turned off. Maybe this helps, regards, Mathias |
Re: Layout dxl not working Mathias Mamsch - Tue Dec 03 09:15:23 EST 2013 Hey Werner, does the DXL actually fail with an error (i.e. after loading the view, do you see an error message in the view column) or does the DXL Layout just pop up the DXL Interaction window with the errors and then show a result? If the DXL is not failing, chances are, that the DXL layout is opening a module which will either have a failing DXL Layout, DXL Attribute or trigger attached to it. If this is the case, see if after the first opening of the module other modules are opened invisibly. Close the modules, then open the problematic view a 2nd time. If the error appears again you should be able to find the problematic module, by tracing the load / read / edit /share calls. Just an idea. Another possibility where we have the effect of an error message appearing only once is autodeclare! If your script is turning on autodeclare, then chances are, that the first time you open the view, the layout DXL will fail (since autodeclare is turned off, even if it is the first statement in the file, because the DXL file was loaded before AutoDeclare was activated. We had a discussion about autodeclare here! ). Then for the second time (after the statement has been run), the next time the DXL Layout is loaded autodeclare will be turned off. Maybe this helps, regards, Mathias G'day Mathias - yes, it does both, actually, we do get an error in the DXL interaction window, and all these reported errors are pointing to lines in the code which are commented out AND the layout dxl presents us with an "Error in DXL" statement in the column. at initial load time, BUT, it works after each subsequent load of module or reloading the view. We have not trigger on any module applied in the whole of our database - not any - unless people have applied them without me knowing, but I doubt it because I checked the opened modules after initial load of the module and there is no difference. We also have not a single script with any AutoDeclare on or off - never contemplated this - we always declare variables. Its [ very ] frustrating to investigate this and on top of that the errors which are pointing to lines of the code which are comments. I have opened a PMR and IBM have now the code and test modules to allow them to investigate, I am very curious as to what the outcome will be. Thanks again for all your help, very much appreciated, regards, Werner
|
Re: Layout dxl not working Not reading all the entries in this tread but am browsing. After I wrote this I'm thining [4] is most relevant. [1] No Triggers? Run the attachding "DxlFind.dxl" to find Layouts/Attr-DXL/and Triggers associated with the module. Maybe edit it first and comment out the AttrDXL and Layout calls. Copy the output to Notepad and try to make sense f it. [2] look for "eval_" and "evalTop_" in the code and all libraries it uses. [4] I notice the DXL window sometimes incorrectly reports the name of the offending file, but is still correct as to the offending line number. Thus, if you use library files, look for line "21" in all these files. [5] Layouts may be easier ..err.. quicker to debug; so perhaps convert to attr-DXL after you get it working. [6] You may need to match up each and every double-quote with its corresponding ending double-quote. [7] Be advised that comment block end character "*/" ends ALL blocks; they cannot be nested.
[8] Look for exactly the two characters [\"] in the code. -Louie Attachments DxlFind.dxl |
Re: Layout dxl not working llandale - Thu Dec 05 14:18:38 EST 2013 Not reading all the entries in this tread but am browsing. After I wrote this I'm thining [4] is most relevant. [1] No Triggers? Run the attachding "DxlFind.dxl" to find Layouts/Attr-DXL/and Triggers associated with the module. Maybe edit it first and comment out the AttrDXL and Layout calls. Copy the output to Notepad and try to make sense f it. [2] look for "eval_" and "evalTop_" in the code and all libraries it uses. [4] I notice the DXL window sometimes incorrectly reports the name of the offending file, but is still correct as to the offending line number. Thus, if you use library files, look for line "21" in all these files. [5] Layouts may be easier ..err.. quicker to debug; so perhaps convert to attr-DXL after you get it working. [6] You may need to match up each and every double-quote with its corresponding ending double-quote. [7] Be advised that comment block end character "*/" ends ALL blocks; they cannot be nested.
[8] Look for exactly the two characters [\"] in the code. -Louie Thanks Louie for the script, appreciated. I ran it and got a result of none, but one - it reported >>>>>>>>TriggerDXL-Database 'dynamic 1': FoundIn 'Database' post-drop-object: I assume it must be one trigger coming with DOORS preinstalled , active, or someone has placed a trigger into the database and I dont know about. not sure which, gotta keepp diggin' on that one. I took all comments out of the script and re-run it, same error. I went thru with a very fine toothcombe and checked for all comments to be correct. With the PMR I opened, I got asked to send it to IBM, under NDA agreement etc, and it was said that attributes starting with underscores are not acceptable. Ok, my mistake, then I replaced all attributes with acceptable names and it started to run better. Lesser syntax errors but, it is now reporting different weird errors, which we never had before, like reporting that a declared array, a proper declared array I might add, is now suddenly out of bounds... go figure ... I have also converted the code to attr-DXL, to the same affects. no change. its sooo frustrating. I wish I could share the code here, shame. Thank you all for your continuuing support. werner
|
Re: Layout dxl not working wernerK - Fri Dec 06 00:11:53 EST 2013 Thanks Louie for the script, appreciated. I ran it and got a result of none, but one - it reported >>>>>>>>TriggerDXL-Database 'dynamic 1': FoundIn 'Database' post-drop-object: I assume it must be one trigger coming with DOORS preinstalled , active, or someone has placed a trigger into the database and I dont know about. not sure which, gotta keepp diggin' on that one. I took all comments out of the script and re-run it, same error. I went thru with a very fine toothcombe and checked for all comments to be correct. With the PMR I opened, I got asked to send it to IBM, under NDA agreement etc, and it was said that attributes starting with underscores are not acceptable. Ok, my mistake, then I replaced all attributes with acceptable names and it started to run better. Lesser syntax errors but, it is now reporting different weird errors, which we never had before, like reporting that a declared array, a proper declared array I might add, is now suddenly out of bounds... go figure ... I have also converted the code to attr-DXL, to the same affects. no change. its sooo frustrating. I wish I could share the code here, shame. Thank you all for your continuuing support. werner
hello all - we have reached a solution, I have closed the PMR problem #1 - we had underscores infront of attribute names - ouch - took them out - as mentioned and it got better problem #2 - found a single dxl attribute which brought up the dxl syntax error - wow - not easy to find that one now its working again - nicely - well, now we going to improve it ....
Thanking you all for your assistance and most of all patience .
cheers werner
|
Re: Layout dxl not working wernerK - Mon Dec 09 17:11:18 EST 2013 hello all - we have reached a solution, I have closed the PMR problem #1 - we had underscores infront of attribute names - ouch - took them out - as mentioned and it got better problem #2 - found a single dxl attribute which brought up the dxl syntax error - wow - not easy to find that one now its working again - nicely - well, now we going to improve it ....
Thanking you all for your assistance and most of all patience .
cheers werner
Hi, I' ma bit surprised by "attributes starting with underscores are not acceptable". Is it really true??? Because all my DXL attributes start with an underscore...
FYI I also ran the DXL sent by Louie (thaks to you) an found out that 3 triggers where running: modid(stored;running on Root Folder) with the following code Trigger t = current ; Object o = object(t) ; status(module(o), uniqueID(item(fullName(module(o))))) seems to be that thing that writes the module id at the bottom left of a module and two other ones: "dynamic 0" and "dynamic 1" without any code behind... What are they here for?? Who knows?
regards, alain
|
Re: Layout dxl not working adevicq - Tue Dec 10 04:09:00 EST 2013 Hi, I' ma bit surprised by "attributes starting with underscores are not acceptable". Is it really true??? Because all my DXL attributes start with an underscore...
FYI I also ran the DXL sent by Louie (thaks to you) an found out that 3 triggers where running: modid(stored;running on Root Folder) with the following code Trigger t = current ; Object o = object(t) ; status(module(o), uniqueID(item(fullName(module(o))))) seems to be that thing that writes the module id at the bottom left of a module and two other ones: "dynamic 0" and "dynamic 1" without any code behind... What are they here for?? Who knows?
regards, alain
Hi, so yes, its true - no underscores are highly recommended, gets you into troubled waters. not sure about your trigger question,sorry, cannot help you there. cheers |
Re: Layout dxl not working adevicq - Tue Dec 10 04:09:00 EST 2013 Hi, I' ma bit surprised by "attributes starting with underscores are not acceptable". Is it really true??? Because all my DXL attributes start with an underscore...
FYI I also ran the DXL sent by Louie (thaks to you) an found out that 3 triggers where running: modid(stored;running on Root Folder) with the following code Trigger t = current ; Object o = object(t) ; status(module(o), uniqueID(item(fullName(module(o))))) seems to be that thing that writes the module id at the bottom left of a module and two other ones: "dynamic 0" and "dynamic 1" without any code behind... What are they here for?? Who knows?
regards, alain
"Stored" Triggers reside in Modules/Projects/Database. "Dynamic" triggers exist only on the user's client and are removed when the corresponding module closes. (Not sure how dynamic Project triggers behave). Most common use of Dynamic triggers is to close a module-scoped dialog box when the module itself closes. "builtin" triggers are used by DOORS to fire off the other triggers; don't know nor care about the what/why/how of them. Ignore them. You cannot retrieve the DXL code of Dynamic (nor builtin) triggers; guess it would get clumsy since the "code" is a function call. the code that deploys a dynamic trigger continues to "run" until the trigger is removed (actually it is "waiting"). You don't care about that fact, but there are some obscure scenarios where it matters. The DOORS client creates two dynamic triggers at startup time, associated with Discussion [1] drag and [2] drop events. Ignore them. That stored code looks odd to me. Seems likely someone installed it and then forgot about it. Perhaps you could let us know the type and event, such as post-open-module trigger; of if I guess correctly in this case a post-sync-object trigger. "Odd" because it has the event of an "object" but only displays info about the "module". -Louie
|
Re: Layout dxl not working wernerK - Wed Dec 11 00:16:30 EST 2013 Hi, so yes, its true - no underscores are highly recommended, gets you into troubled waters. not sure about your trigger question,sorry, cannot help you there. cheers attributes starting with underscores not acceptable???? Our company DOORS support recommends that any attribute we add should have the underscore first. This way, it differentiates from the system attributes and any standard attribute the support people include. It also puts our attributes at the top of the list when you look at the attribute list. So, I don't see where defining attributes starting with underscores would be not acceptable. We have never had a problem with defining attributes starting with underscores. However, I did review some other forum entries and found that variable names and functions used in dxl code should not use underscores at the beginning of them, as it confuses the interpreter and sometimes steps on DOORS function calls. Maybe the concern should be that attribute dxl or layout dxl needs to watch out in their naming conventions. Just want to try and pass along some more information. Greg |
Re: Layout dxl not working llandale - Tue Nov 26 09:43:48 EST 2013 A 1600 line Layout is surely a disaster, as it can run multiple times per second for each displayed objects. Definately turn that into an Attr-DXL. "syntax" errors in a line are almost always fixed by adjusting some previous line; so we'd want to see ings 19, 20, 71, and 72 as well. In any event we would want to see the 1st and 2nd DXL errors, not those further down. I note that since you are getting DXL errors at very early lines, it seems that you could indeed post the 1st 22 lines of your code. As for causes; let me brain storm: [1] I wonder if you have some post-module-open trigger for all modules in the database that issues some kind of "evalTop_" command. This command resolves the include file references for FUTURE layouts. [2] My hackles are up vis-a-vis some PTSD I've experienced working with layouts. I wonder, does this view feature OTHER layouts or attr-DXL in columns adjacent to this one? If so, copy the view then remove those columns and see if you still have a problem. If you do not maybe I can <explain> as best I can what just happened. [3] Do you have some kind of <pragma encoding> command in your offending code? -Louie All, FYI I have found the reason of my problems. As I said, the first time I run one of my DXLs to export a module, it always fail with a syntax error. Then if I run it again, it runs normally... After having read a little bit more the lines in error, I have found out that all the errors concern a function which name starts with an underscore. I renamed all these functions and everything work fine, even the firt time I run the scripts... It's Xmas, no? So, DXL hates underscores not only in attribute names but also in function names!! Happy Xmas to all of you. Alain
|